Stop concurrent withdrawals from grabbing the same UTXO - #569

What was going wrong

Two withdrawals from the same wallet, submitted at nearly the same time, could pick the same UTXO. When that happened one of the two transactions replaced the other on the network (RBF) instead of both going through.

The cause was a gap between two steps: NodeGuard would read which UTXOs were free, choose some, and only afterwards mark them as taken. Two requests that both did the reading before either did the marking would happily choose the same coin. This affected both automatic coin selection and the "use exactly these UTXOs" flow (Changeless withdrawals and channel opens, e.g. from the UI's UTXO selector) — the latter had no protection at all.

What changed

Choosing UTXOs and claiming them is now a single operation that can't be interleaved with another one. There are two entry points, depending on who picks the coins:

• LockUTXOs — the caller already knows which UTXOs it wants. Checks nothing else has them, then claims them.
• SelectAndLockUTXOsAsync — the service reads what's available, picks enough to fund the request, and claims it.

Both hold a mutex for their whole duration, so the read/choose/claim sequence is indivisible. The mutex is released before callers go on to build a PSBT, since that's the slow part and doesn't need protecting.

A few things fall out of that:

• Fee bumping (RBF) deliberately reuses the UTXOs of the request it replaces, so that specific case is still allowed through. Only a UTXO held by some other request is rejected.
• Picking a UTXO someone else already took now surfaces as a message ("already locked or frozen") rather than silently going ahead — over gRPC as FailedPrecondition, in the UI as an error toast.
• Waiting on the mutex has a timeout. If a future change ever introduces a deadlock, it fails with a clear error instead of hanging forever.

Also fixed a pre-existing bug found along the way: the query that ignores one specific request when checking for held UTXOs had a parenthesisation mistake, so the "ignore" only actually worked when that request happened to be in one particular state. Nothing exercised that combination before; the fee-bump case above is the first thing that relies on it.

Notes for review

• The mutex is process-wide rather than per-wallet. Selections for different wallets now wait on each other, which costs a little parallelism, but a selection is only a handful of short database/NBXplorer reads and these are human-initiated operations. The per-wallet version needed a keyed lock table with reference counting and cleanup, and it wasn't worth the complexity.
• UTXOs are claimed slightly earlier than before — before the PSBT is built rather than after. That has to happen inside the same protected step as choosing them. If the build then fails, the request is marked as failed, and failed requests don't hold UTXOs, so they free themselves.
• WithdrawAllFunds still works out its amount outside the protected step, as it did before this PR. If another request takes some coins in between, the amount goes stale and the selection can no longer cover it — that's detected and fails the request with an error rather than under-funding it, so the exposure is a rare retry, not a wrong transaction.

Testing

Unit tests cover the locking and conflict rules, plus the pre-existing bug above (across every state it applies to).

Two end-to-end tests run against a live NodeGuard and bitcoind:

• many concurrent withdrawals from one wallet, asserting no two transactions ever share an input
• two withdrawals that explicitly name the same UTXO, asserting exactly one wins and the other is cleanly rejected

dotnet test test/NodeGuard.Tests --filter "Category!=E2E" for the unit tests; just test-e2e for the rest.